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REMARKS 

Claims 1-6, 8-13, 15-17, 19-31 are pending in the present application. In the 
Office Action mailed June 6, 2005, the Examiner rejected claims 1-6, 8-13, 15-17, 19-23, 
and 30-31 under 35 U.S.C. § 103(a) as being unpatentable over Hube et al (USP 
5,442,541) in view of Fenstemaker et ah (USP 6,490,684 BI). Claims 24-29 stand 
rejected under 35 U.S.C. §103(a) as being obvious over Hube et ah in view of 
Applicants Admitted Prior Art and further in view of Fenstemaker et ah 

In the rejection of claims 1-6, 8-13, 15-17, and 19-31, the Examiner maintained a 
previous rejection that the claimed invention was unpatentable over the combination of 
Hube et ah and Fenstemaker et ah While Applicant believes the remarks presented in the 
Response filed March 3, 2005 sufficiently set forth the patentable distinctions between 
that which is being claimed and that suggested by the combination of references; 
nevertheless, Applicant requests consideration of the remarks hereinafter which are 
believed to further highlight the shortcomings of the Examiner's rejection. 

The Examiner has maintained, notwithstanding a lack of direct teaching or 
suggestion in the references themselves, that Hube et ah and Fenstemaker et ah, when 
considered together, teach the transmission of an electronic request over a public or first 
communication interface and the transmission of a software key or cnablcr over a private 
or second communication interface. The Examiner's rejection ignores however that 
Hube et al. teaches directly away from such a bifurcated communication system. 

Applicant agrees that Hube et al. suggests communication over one of a number 
of communication types, such as telephone lines, LANs, WANs, cellular phone channels, 
infrared links, and serial channels. However, regardless of the type of communication 
channel, Hube et al. is adamant that only one communication channel is used to make a 
software enablement request and enable the desired software. In fact, Hube et al. states 
that it is an object of its invention to provide such a "common communication interface". 
Specifically, Hube et al. states, "Hie invention relates to a system for the selective 
enablement of machine features and more particularly, to the selective enablement of 
machine features from a remote station over a common communication channel." Coh 1, 
11. 6-10. Hube et al. continues, "it is still another object of the present invention to 
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selectively change the features of machine by remote designation or feature downloading 
from a central control station over a common communication channel." Col 2, 11. 59-63, 
The description of Fig, 2 of 5,442,541 further highlights that a single communication 
channel is used to make a software enablement request and enable the software. 

In this regard, the reference discloses that the 4 *rcmote communication system 
including remote host 157 [is] interconnected to Control 71 of machine 30 through a 
suitable channel such as telephone line 175..." Col. 10, 11. 15-21. Hubc ct aL further 
teaches that "a computer such as PC 1 59 with suitable input such as keyboard 1 80 is 
provided at the remote host 157 for use in establishing communication with modem 182 
for transmission 0 f data from machine 30 via line 1 75 to host 1 57 and from machine 1 57 
to machine 30 ." Col. 10, 11. 44-48, emphasis added. 

While it is clear from Hube ct ah that communication between the remote 
machine and host is over a common communication channel, the reference -further 
teaches that "access to the new upgrade features is enabled through a remote interface 
communication interface," CoU 14, IL 18-19. To this end, Hube et al. teaches that 
"customers use the remote interface to request downloading of passwords or of codes to 
the system or remote host" whereupon "the remote host then enables the new features 
with the appropriate instructions and data communications over the shared 
communication line." Col. 14, U. 20-24. 

In operation, Hube el al. teaches that an operator at the remote station or at a 
given machine identifies a feature to be enabled and "enter[s] a feature enable mode". 
Sec col. 15, 11. 28-30. Accordingly, Hubc et al. explicitly teaches the remote station 
communicates to the machine via the common communication interface to initiate a 
feature enablement or, in the alternative, a user at the machine initiates the feature 
enablement process by establishing communication between the machine and remote 
station over the common communication channel. In either case, however, the request to 
enable a software option is transmitted over the same communication channel that a 
lc key" is transmitted to "unlock" a locked machine feature. That is, while Applicant 
disagrees that a WAN is, by definition, a public communication interface and that a 
telephone, email, or FAX interface, by definition, are private interfaces, as asserted by the 
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Examiner; nevertheless, Hube et al. leaches a single and common communication 
interface so, therefore, Hube et al. either teaches communication over only a single public 
interface or only a single private interface, but not both. 

In combination with Hube et al, the Examiner relied upon Fcnstcmaker et ah 
While Fenstemaker ct al. teaches an 4 "ultrasound method and system for enabling an 
ultrasound device feature," there is no teaching or suggestion that a request for feature 
enablement is made over one communication interface and a password or key to enable 
the software is transmitted over a different communication interface. Fenstemaker et al. 
simply teaches that "a user requests a key from a remote source" and <c the key is 
generated by the remote source (step 420) and transmitted to the ultrasound device 100 
via the key receiver 150, which can be, for example, a network link or modern (step 
430)." CoL 3, 11. 29-30, 34-37. Further, one skilled in the art, given the explicit 
teachings of Hube et al., would conclude that the communication disclosed by 
Fenstemaker et al. is via a common communication channel or interface. If a 
contradictory assumption could be made, then one skilled in the art would not 'be 
motivated to combine the references given that Hube et aK explicitly teaches a single and 
common communication channel for requesting software enablement and transmitting a 
key to enable the software. 

Therefore, neither Hube et al, nor Fenstemaker et al teaches or suggests separate 
communication interfaces for requesting feature enablement and transmitting a key to 
enable the feature. As such, given that claims 1, 17, and 24, each call for, in part, 
communication over two different communication interfaces or connections, it is 
believed that claims 1,17, and 24, as well as those claims depending therefrom, to be in 
condition for allowance. 

The Examiner rejected claim 9 under 35 U.S.C. § 103(a) as being unpatentable 
over Hube et al. in view of Fenstemaker et al. The Examiner stated that "Hube docs not 
explicitly teach receiving a host ID input, wherein the host ID corresponds to a physical 
location of a device." Office Action, January, 3, 2005, p. 4. The Examiner stated that 
Fenstemaker et al. teaches 'Svherein the host ID corresponds to a physical location of the 
device (see for example, Ethernet Hardware id) [col. 3, IK 31-40, and col. 4 IK 45-57, coK 
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5 11. 1-13]." Id. The Examiner further stated that, "Therefore it would have been obvious 
to one having ordinary skill in the art at the time the invention was made to include a 
method of receiving a host id that corresponds to a physical location of the device as 
taught by Fenstemakcr and implement it within the system of Hube, in order to generate 
unique keys for each device according to their identification." Office Action, pp. 4-5. 
Applicant respectfully disagrees. 

Claim 9 calls for a remote centralized facility that includes a computer 
programmed to receive a host ID input, wherein the host ID corresponds to a physical 
location of the device. Neither Fenstemaker et al. nor Hubc ct al. teaches or suggests a 
computer at the centralized facility to include a computer programmed io receive a host 
ID input, wherein the host ID corresponds to a physical location of the device. The 
Examiner concluded that Fenstemaker et aL teaches that the host ID corresponds to a 
physical location of the device and provided references in Fenstemaker et al- to support 
the conclusion namely, col. 3, 11* 31-40, and col. 4 11 45-57, coL 5 11. 1-13. However, 
these references do not teach or suggest a computer programmed to receive a host ID 
input, wherein the host ID corresponds to a physical location of the device. Instead, the 
references teach key generation and transmittal (see coL 3, 11.. 34-40), key composition 
and methods of using the key (see col. 4, 11.. 45-57), and key encryption and decryption 
using public and/or private keys (see col. 5, 11. 1-13). None of these passages in the 
reference teaches or suggests the remote centralized facility as having a computer 
programmed to receive a host ID input that corresponds to a physical location of the 
device. 

Furthermore, as stated above, the Examiner asserted that Fenstemaker et al. 
Leaches that "the host ID corresponds to a physical location of the device (see for 
example, Ethernet Hardware id)." Office Action, January 3, 2005, p. 4. One skilled in 
the art would not recognize that an Ethernet hardware ID corresponds to a physical 
location. That is, the Ethernet hardware ID identifies the hardware but not^the physical 
location of the hardware. Also, Fenstemaker et al. "fails to teach or suggest the receipt of 
an Ethernet hardware ID by a computer at a remote centralized facility. Fenstemaker et 
al. teaches that u [ojther public keys can include an Ethernet hardware ID, a number 
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generated by a block-dongle located on a port, or any other unique number stored in the 
ultrasound device." Col. 5, 11. 10-13. Thus, while the key may include an Ethernet 
hardware ID, Fenstemaker et al. fails to teach or suggest receiving a host ID input, 
wherein the host ID corresponds to a physical location of the device. 

Since the prior art fail$ to teach each and every element of the claimed invention, 
a prima facie case of obviousness has not been established. Applicant believes that claim 
9 and the claims that depend therefrom arc patentable over the prior art 

Therefore, in light of at least the foregoing, Applicant respectfully believes that 
the present application is in condition for allowance. As a result, Applicant respectfully 
requests timely issuance of a Notice of Allowance for claims 1-6, 8-13, 15-17, and 19-31. 

Applicant appreciates, the Examiner's consideration of these Remarks and 
cordially invites the Examiner to call the undersigned, should the Examiner consider any 
matters unresolved. 
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